Génération de tâches sur les révisions et renouvellements

Alerte sur les révisions et renouvellements

Entité

Type

Code

Valeur client

Libellé

VDEF

abOalrt0s1

code_even

REV

Code événement utilisé par défaut pour les alertes sur révision de bail

VDEF

abOalrt0s1

nbj_alrt

100

NOMBRE DE JOUR pour génération événement ALERTE sur révision de bail.

Date de révision à prendre en compte pour génération d’Alerte doit être inférieur à la date de lancement du traitement + ce paramètre en JOUR

VDEF

abOalrt0s1

profil

2

Création Événement associé à une révision.

Profil autorisé à modifier le code événement  sur écran de lancement des traitements de génération

VDEF

abOalrt0s1

code_rn

REN

valeur par défaut code événement renouvellement

VDEF

 

abOalrt0s1

nbj_ren

100

NOMBRE DE JOUR pour génération événement ALERTE sur renouvellement de bail.

Date de renouvellement à prendre en compte pour génération d’alerte.

Doit être inférieur à la date de lancement du traitement + ce paramètre en JOUR

Écran

L’écran des types de baux (mot clé TYBA) affiche deux nouveaux champs :

Fonctionnement

  • Type d’événement et code action

La création des alertes est basée sur la génération d’évènements et d’actions dont les codes sont contenus dans les paramètres code_even (alerte révision) et code_rn (alerte renouvellement).

L’existence de ces 2 codes est donc obligatoire.

Types d’évènements 

Codes action 

  • Types de baux

Les alertes qui vont être créées le seront par rapport à :

  • la date de prochaine révision pour les alertes de type REV
  • la date de fin de bail pour les alertes de type REN

Toutefois, un délai supplémentaire sera ajouté à ces dates de manière à ce que le gestionnaire puisse avoir le temps de faire le nécessaire. Ces délais supplémentaires devront être saisis sur les types de baux concernés :

Exemple : si le champ Alerte révision est valorisé à 30 jours et que la date de prochaine révision est fixée au 1/1/2019, l’alerte sera créée au 2/12/2018

NB : si ce délai n’est pas saisi, aucune tâche ne sera créée.

Génération des alertes

L’accès au lanceur est le suivant :

L’écran se décompose en trois parties :

  • Sélection des baux : critères de lancement du traitement
  • Révision : éléments rattachés à la création de l’alerte sur la date de prochaine révision
  • Renouvellement : éléments rattachés à la création de l’alerte sur la date de fin de bail

La sélection

Ce traitement peut être lancé de différentes manières :

  • Pour tout le portefeuille : ne renseigner aucun critère de sélection. Seuls les types de baux pour lesquels un nombre de jour aura été paramétré seront sélectionnés
  • Sur une partie du portefeuille : renseigner le critère de sélection correspondant à votre choix : liste type de baux, propriétaire, immeuble…

    • Il est également possible d’utiliser deux critères de sélection simultanément. Mais pour ce mode, la liste de type de baux est obligatoire (Ex : Liste type de Baux + Propriétaire ou Liste type de baux + Immeuble).

    Il ne sera donc pas possible de sélectionner Propriétaire et Immeuble en même temps.

Le choix des alertes

Une fois la sélection faite, il est nécessaire de contrôler ou compléter les codes événement liés à la révision ou au renouvellement.

Rappel :

  • La date à laquelle l’alerte pour la révision va être créée correspond à la date de prochaine révision  + la valeur du paramètre nbj_alrt
  • La date à laquelle l’alerte pour le renouvellement va être créée correspond à la date de fin de bail  + la valeur du paramètre nbj_ren

Si l’alerte sur la date de révision ne doit pas être faite, le code évènement lié à la révision doit être mis à nul. Il est également possible de mettre le paramètre code_even à nul. De cette façon, il ne sera pas nécessaire de remettre le code à nul systématiquement. Même remarque pour la partie renouvellement avec le paramètre code_rn.

Il est également possible de modifier l’objet qui sera utilisé pour la création de l’alerte

Enfin, le mode de génération de l’alerte doit être sélectionné :

Remarque : ces différents modes d’implémentation n’ont d’effet que dans le cas où des évènements existent déjà)

  • Ajouter un nouvel événement

    • Autant d’évènements seront créés que le traitement sera lancé. Si le traitement est lancé 3 fois sur le même locataire, le gestionnaire récupèrera 6 alertes (3 révisions + 3 renouvellement).

  • Modifier l’événement

    • Cette option permet de modifier le libellé d’une tâche déjà créée.

  • Supprimer l’événement existant et en créer un autre
  • Ne rien faire

    • Cette option permet d’éviter de créer plusieurs évènements pour le même locataire.

Remarques :

  • seuls les locataires non sortis sont sélectionnés,
  • l’accès aux codes évènements est géré par paramètre. Tous les utilisateurs ne peuvent pas modifier cette information
Résultat

Une fois le traitement lancé, des évènements sont automatiquement créés et des tâches sont alors consultables dans l’agenda du gestionnaire :

  • Date : correspond à la date sélectionnée (date de fin de bail ou date de prochaine révision selon les cas) à laquelle a été soustrait le nombre de jour paramétré sur le type de bail.

    • Dans l’exemple, la date de fin de bail était positionnée sur la fiche locataire à 31/12/2018, le type de bail à 30 jours è31/12/2018 – 30jours = 01/12/2018.

  • Action : libellé indiqué dans le cadre Objet dans l’écran de lancement du traitement auquel vient s’ajouter automatiquement certaines informations.

    • Pour la révision :

    • Date de prochaine révision
    • N° indice et valeur indice lié à la date de prochaine révision
    • Type de bail
    • Date de fin du bail

    Pour le renouvellement :

    • Date de fin de bail
    • Type de bail
    • Nom du propriétaire et numéro

  • Responsable : le salarié à qui va être affecté la tâche dépend du paramétrage.

    • Dans un premier temps, c’est le code responsable associé à l’action qui est sélectionné.

    Ensuite, après lecture du paramètre  type : abBbail0s1 // code : resp_ge, on identifier le responsable soit au niveau de l’immeuble (valeur du paramètre à I ou R), soit au niveau du propriétaire (valeur du paramètre à P)

Attention:

Afin d’éviter de générer des alertes sur des baux pour lesquels les échéances sont trop lointaines et qui viendraient donc surcharger l’affichage des tâches, des paramètres permettent de limiter la sélection des baux.

  • Nbj_alrt

    • Seuls les baux pour lesquels la date de prochaine révision est inférieure à la date du jour + la valeur du paramètre seront sélectionnés

    Ex : date de prochaine révision : 15/05/2018 – valeur du paramètre : 1000 – date du jour : 14/03/2018

    è 14/03/2018 + 1000 jours = 8/12/2020

    La date du 15/05/2018 étant inférieure à celle du 8/12/2020, le bail sera sélectionnée

  • Nbj_ren

    • Seuls les baux pour lesquels la date de fin de bail est inférieure à la date du jour + la valeur du paramètre seront sélectionnés

 

La suppression des alertes

Sortie locataire

Lors de la sortie d’un locataire pour lequel des évènements REV ou REN (ou autres selon le paramétrage), existeraient, ceux-ci seront supprimés. Un message avertira l’utilisateur :

Traitement

Un traitement de purge permet de supprime des taches qui auraient été créées à tort.

Cet écran est accessible via les menus suivants :

L’écran se présente comme cela :

Les mêmes critères de sélection que ceux présents sur l’écran de génération sont disponibles : liste type de baux, immeuble, propriétaire…

Par défaut, le code événement est positionné à REV (= révision). Pour purger des évènements liés au renouvellement, il suffit de zoomer et de rapatrier le bon code (REN).